While different access domains in cellular networks are being deployed, the same handset is used to operate and receive services in the various domains. Feature parity across the different domains is desired or mandated by cellular operators, and the end user handset desirably supports features and services across the network domains without interfering with the user experience. User-based supplementary services updates is one of the services that is desirably transparent to the end user, while the user moves in and out of different network domains.
The user handset desirably receives the same services offered in both network domains. Standard interfaces have been defined in wireless domains, such as IMS (a packet-switched (PS) network) and circuit-switched (CS) networks, to allow the user to change his/her supplementary services settings, regardless of which domain the handset is operating. Given that the access network, core network, call processing servers, and backend provisioning systems are generally separated in both domains, a solution is desired to synchronize the user supplementary services updates or settings that can occur or be initiated in either network. More specifically, in deployments where the subscriber data is sorted in separate databases where, for example, the Home Location Register (HLR) and Home Subscriber Server (HSS) are based on separate platforms (e.g., CS network and PS network, respectively), and no subscriber data management solution has been deployed to provide unified data convergence, a solution is desired to synchronize the user Supplementary Services (SS) data changes in both databases when they are applied by the end user in either domain (the CS or PS network) and/or by an operator in either network.
In addition, for operators that do not have a common backend provisioning system that replicates SS data changes to both CS and PS subscriber databases, such operators apply SS data changes twice, one on each database. This adds operating expenses (OPEX) and process complexity on the operator side. A solution is therefore desired to automate the backend SS data update synchronization across multiple domains.
One known solution to synchronize SS data across the domains is to use Signaling Transfer Point (STP) screening to forward all SS data changes related Mobile Application Part (MAP) traffic to a synchronization node before being the changes are sent to the HLR. The intercepting synchronization node will then update both HLR and HSS in both domains, CS and PS. The shortcomings of this solution are as follows.
(a) The synchronization node is in the path of all subscribers including non-PS (e.g., Legacy subscribers with handsets not capable of 4G) subscribers. This creates an additional hop in the network, and makes the synchronization node a dependency for SS updates for non-4G subscribers.
(b) STP changes are required, and in some deployments these changes are constrained under contracts which will cause additional financial costs on the operator.
(c) The solution will not work if STP does not support screening based on originating node address and MAP operational code (OpCODE).
(d) The solution adds more complexity to the synchronization node, because, desirably, the synchronization node avoids updating HSS for non-4G subscribers. This traffic will be only pass-through, but HSS check is still used for every received request. This solution also adds more capacity requirements on the synchronization node and HSS, because the node and server check and then pass through requests for 2G/3G (not 4G capable) subscribers that are not in the HSS database.
(e) Backend updates done in the CS domain cannot be transferred to the 4G domain if the operator does not have a common backend provisioning system that duplicates the updates to both CS and 4G databases. This is a common problem when introducing Voice-over-4G as an independent solution.
(f) If the synchronization node goes down, both 4G and non-4G subscribers will be affected.
Another known solution is the use of an external Database Synchronization Server (DSS). The DSS will interface to both HLR and HSS, and will update each when a change occurs in either subscriber databases. The shortcomings of this solution are as follows.
(a) There are significant dependencies on the HLR and HSS vendor(s) and on the availability of a direct interface to the DSS.
(b) This is a relatively expensive solution, typically offered by the same vendor of the HLR and IMS HSS.
(c) Periodic database audits are generally required in case the synchronization server fails.
(d) This solution employs a complex DSS solution for database redundancy and real-time replication.
(e) The complexity of the solution increases if both HLR and HSS databases are based on different database engines and protocols, e.g., Oracle vs IBM or Microsoft databases.
(f) This solution employs high interoperability effort.
Another known solution is to anchor all call origination and call termination in the IMS domain. This includes 2G/3G calls. All terminating services will be removed from HLR and applied in IMS domain. SS data changes applied in CS are barred at the HLR. All SS data changes done by the user equipment (UE) are made in the PS domain. The shortcomings of this solution are as follows.
(a) The solution does not address originating services synchronization.
(b) All calls including 3G/3G are routed to the IMS, which increases capacity requirements on the IMS network.
(c) CS calls traverse IMS domain when not otherwise necessary to do so, causing inefficient call routing and inefficient network traffic load distribution.
A solution that overcomes one or more of the above shortcomings is desired. Systems and methods that can update all SS data without impacting non-PS (e.g., non-VoWIFI) subscribers and without changing configuration of existing Signaling System 7 (SS7) infrastructure, without substantially increasing OPEX and capital expenditure (CAPEX) for the operator, and/or without adding complexity on the operator backend provisioning system are further desired.
It will be appreciated that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of illustrated embodiments of the present invention.